Travel 2.0
This guide is intended as a manual and overview for the +travel 2.0 upgrade, how it works, and how it fits together. It's largely targetted to staff, and is Charoscoru-centric, but if you're interested in how things work behind the scenes, it might be a fun read. Bear with, it's very bare bones, somewhat technical, and written by me - thus, while it may be factually accurate, it may be a bit of a snoozefest. Overview and Abstract The +Travel system is designed to simulate distance and scope of travel on a MUSH environment by adding real-life time to movement across the roleplay grid. It consists of several components and is far wider than a simple Global system - its complexity, in fact, is built into the different 'scales' to which the system must be built. At its heart, however, taken as an abstraction, +travel is capable of simulating anything from walking to starships, horses to flight. Please note that +travel is an abstraction - I cannot stress that enough. The concepts here are fundamental to the systems operation, and while the Horse aspect, used extensively on Chia, is used repeatedly as an example, it is not limited by anything more or less than imagination in its application.M Terminology Ratio - the golden heart of the +travel system, the Ratio is a number that represents 'seconds per minute of travel time'. To be more specific, every +travel exit set on a room has a base time set - this is the time used in +walk, and is representative of a Ratio of 'Sixty Seconds to Travel One Minute of Base Time.' If you set a Ratio of 30 on a travel command, it means that for every minute in your BASE value for that exit, it takes the traveller thirty seconds of travel time. To put it another way: If you use a +travel time of 10 minutes: A ratio of 60 means it takes 10 minutes of real time (600 seconds) A ratio of 30 means it takes 5 minutes... (300 seconds) A ratio of 20 means it takes 3.33 minutes (200 seconds) Ratios may also go above 60, representing a 'slower than default' pace. Speed Speed is a 'modifier' attribute set on a travel parent representing the variations in speed between object types. It is NOT required, and is user-defineable, but referenced here. Efficiency Efficiency is a 'modifier' attribute set on a travel parent representing variations in 'engine efficiency' between object types. It is NOT required, and is user-defineable, but referenced here. Fuel Cost The base cost of using a movement mode. Fuel cost IS REQURED in the travel() global function, but may be set to 0. SS_HUNGER The default attribute checked for Fuel on all objects using +travel. Fuel Attribute The storage attribute that tells +travel what to use for hunger when it is NOT appropriate to use SS_HUNGER - say, a starship, where fuel is a consideration. DB Attribute A storage attribute on the travelling object referenced by the +travel system. +travel base commands All players, and, by extension, all objects capable of executing base commands from the master global room have access to the following two movement commands: +walk (moves through the referenced +travel exit with a default ratio of 60) +run (moves through the referenced +travel exit with a default ratio of 30). These use the following attributes on the +travel 2.0 object: DB`Walk`Ratio: change to alter walk speed (not reccomended) DB`Walk`Cost: cost, in default SS_HUNGER, to use this movement mode. (Default is 0) DB`Run`Ratio: change to alter run speed (default is 30) DB`Run`Cost: cost, in default SS_HUNGER, to use this movement mode. (Default is 10 units) Changing these DB attributes is a GLOBAL change, affecting all items using these attributes. These DB attributes ARE NOT evaluated before use in the default 2.0 parent. The other default commands are: +stop: Stops both the player and the object in which they currently stand, if applicable. +eta: Shows approximate time remaining for the journey for the player, or the object in which they currently stand, if applicable. +go (admin only): allows admins to move with no travel time through a +travel exit. 'follow ', a built-in, hardcoded command, is recognized and accounted for, allowing 'grouping' of players behind a primary traveller. All following objects move at the spead of the 'leader'. Note that follow DOES NOT work in rooms set DARK. The global function travel() is also stored on this object in the attribute 'FN`MOVE'. Travel() requires the following format: travel(Dbref, Direction, Ratio/factor in seconds per minute, Cost of travel,travel name) Dbref is the dbref of the object moving, in the form '#'. Direction is the name of the +travel exit being used. (an error message is generated if this is invalid.) Ratio/factor in seconds per minute: the travel Ratio, as noted above. Cost of travel: The cost of travel in units, without qualification. (The system references the 'DB`FuelAttr' attribute on the travelling object, defaulting to SS_HUNGER) Travel Name: Used to activate messages for travel. The system looks for 'MSG``AWAY' for the remit used when the object finally leaves, 'MSG``IN for the remit used when the object arrives at its destination, 'MSG``STOP` for the message used when the +stop command is issued, 'MSG``REMIT' for the message issued when the function is invoked, and 'MSG``NOTENOUGHFUEL' if the object does not have enough base fuel to travel in this manner, emitting all as approprate. +run uses the following message set, by way of illustration: MSG`RUN`AWAY: name(%0) dashes away toward the %1. MSG`RUN`IN: name(%0) dashes in at a run. MSG`RUN`NOTENOUGHFUEL: ansi(hr,-) You are too hungry and exhausted to run! MSG`RUN`REMIT: name(%0) takes off at a run toward the %1. MSG`RUN`STOP: name(%0) stops running. Note that all MSG attributes are evaluated before being passed, expecting %0 as the dbref of the enactor, and %1 as the exit name. Additionally, note that travel() is ADMIN RESTRICTED, and thus relies on the notion that the invoking object MUST be set WIZARD. The Power of travel() For basic walking and running, the core +Travel object handles all of the gory details itself. The real power of travel() is as an API framework for creating Travel Parents - things like Horses, Starships, and other conveyances capable of far more complex action. The +Travel 2.0 system DOES NOT explore the possible scope of these objects, rather, it exists as an easy way for staff to create movement commands on those objects using the existing framework, transferring the burden of movement commands to those objects and removing them from the master room. As travel() can accept derived values, literally ANYTHING can be moved with its own algorithm, whatever that algorithm may be, and derived systems are self-contained in the parent proper. So, Horses are all affected by the Horse Parent, and the core commands are updateable or scaleable for each individual horse under that parent. Practical Limitations, and How Things Move The +travel 2.0 core routine is a process that cycles every thirteen seconds, looking for objects that are moving and checking their eta against system time. If no objects are in queue, then the cycle defaults to a one minute base time, waiting for an object to appear before spooling up for more accurate tracking. In practical terms, this means that travel() will have, depending on circumstance, somewhere between a one second and one minute 'lag' based on current load and at what point in the cycle the object enters the system. Travel times under thirteen seconds are discouraged for that purpose; in fact, any travel time under one minute may take /up to/ a minute regardless of conveyance, speed, and the rest simply because of built-in system lag. Category:Chiaroscuro How Stuff Werx